The present invention relates to communications within a data processing network, and in particular to implementations of the publish/subscribe communications paradigm
Within a messaging network, messages may be delivered from one data processing system to another via one or more “message brokers” that provide routing and, in many cases, formatting and other services. The brokers are typically located at communication hubs within the network although broker functions may be implemented at various points within a distributed broker network.
Many message brokers support a publish/subscribe communication paradigm. This involves publishers sending communications that can be received by a set of subscribers who have registered their interest in receiving communications of particular types, typically without the publisher needing to know which subscribers are interested in which communications. Publish/subscribe allows subscribers to receive the latest information in an area of interest (for example, stock prices or events such as news flashes or store special offers) without having to repeatedly request that information from each of the publishers.
A typical publish/subscribe environment has a number of publisher applications sending messages via a broker to a potentially large number of subscriber applications located on remote computers across the network. The subscribers register with a broker and identify the message types they wish to receive. The subscription information is stored at the broker. In many publish/subscribe implementations, subscribers specify one or more topic names which represent the types of messages they wish to receive. When publishers send their messages to the broker, the publishers assign topic names to the messages and the broker uses a matching engine to compare the topics of received messages with stored subscription information for the registered subscribers. This comparison determines to which subscribers the message should be forwarded. Topics are often specified hierarchically, for example using a character string format “root/topicLevel1/topicLevel2”, to enable topics specified within received messages to be compared with subscriptions using a matching algorithm that iteratively steps through the topic hierarchy.
Another known publish/subscribe environment implements a publish/subscribe matching engine on the same data processing system that has a subscriber application. Publishers send publications (messages) to this system and the publish/subscribe matching engine determines which messages are of interest to the local subscriber application. In the context of the present invention, the term “publish/subscribe broker” is intended to include a publish/subscribe matching engine implemented either at an intermediate network node or at the subscriber's data processing system.
Some publish/subscribe environments include a combination of subscribers that are local to a broker and subscribers that are remote from the broker.
Although subscription matching often involves checking topic fields within message headers, the matching may additionally or alternatively involve checking other message header fields or checking message content and filtering messages based on the additional information. For example, a message broker implementing the Java™ Message Service (JMS) typically allows filtering based on message properties other than message content or ‘payload’. A message broker may perform additional functions, such as formatting or otherwise processing received messages before forwarding them to subscribers. (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc.).
The publish/subscribe paradigm is an efficient way of disseminating information to multiple users, and is especially useful for environments in which the set of publishers and/or subscribers can change over time and where the number of publishers and/or subscribers can be large. Although some subscriptions are ‘non-durable’ (i.e. remain active only while a subscribing application is connected to the broker), many subscriptions are ‘durable’ and remain active until the subscribing application explicitly unsubscribes. When a ‘durable’ subscriber no longer wishes to receive messages, the subscriber can unsubscribe from the broker (or unsubscribe from a particular topic or set of topics).
Although this ability to subscribe and unsubscribe leaves the subscriber in control of which messages they receive, the subscriber has to initiate each subscribe and unsubscribe operation. Subscribers typically require a confirmation reply for each subscribe or unsubscribe operation. Subscription, unsubscription and confirmation messages result in network communication overhead and may result in latency in the performance of each subscribe and unsubscribe operation at the broker. The more frequent the subscribe and unsubscribe operations, the more likely it is that the inherent latency on subscribe operations will cause the subscriber to miss a desired message. In a communications environment that relies on low bandwidth or unreliable connections between a subscriber and a broker, connection problems could also result in a significant delay before the subscriber starts receiving desired messages.
The latency on unsubscribe operations may result in undesirable communications and processing overhead for the subscriber since the subscriber may continue receiving unwanted messages over a slow or expensive network link until the unsubscribe operation can be completed. In the case of a distributed network of brokers that can each subscribe to other brokers, there is potential for a great deal of unwanted network traffic. In the case of durable subscriptions, where the broker queues messages on behalf of an unconnected subscriber, unwanted messages may build up in broker storage space while the subscriber remains unconnected. Queued messages may use too much of the broker's storage space and may result in a surge in network traffic the next time the subscriber connects, causing all of the stored messages to be downloaded to the subscriber. For a mobile subscriber who relies on expensive or unreliable network links and who may not connect for considerable periods of time, the volume of unwanted messages may be large each time the subscriber does connect.